The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
monode	Ready	Preview, Comment	Jun 9, 2026 9:20pm

Greptile Summary

This PR adds a smooth sliding animation to the TPS chart by introducing useSlidingNow (a requestAnimationFrame-driven clock), drawHistory (progressive segment interpolation), and buildTicks (frame-anchored x-axis ticks). The lockfile is also cleaned up by removing duplicate entries, and pnpm-workspace.yaml gains explicit allowBuilds entries for sharp and unrs-resolver.

• drawHistory replaces the most recent history point with a linearly-interpolated "head" that travels from the previous point to the newest one over one inter-arrival interval, making the chart edge slide smoothly rather than snapping on each data arrival.
• buildTicks generates explicit ticks anchored at now (the right edge) and stepping backward, preventing recharts from auto-placing duplicate "now" labels.
• Lockfile / workspace changes remove accidentally duplicated package entries and add standard native-binary allowBuilds allowlist entries.

Confidence Score: 5/5

Safe to merge — the animation logic is well-contained and correctness degrades gracefully under unexpected conditions.

The new animation helpers are isolated to the chart component, recharts explicit domain and ticks props prevent stale axis state, and all edge cases are handled. The one notable concern is that the animation progress formula uses the server-embedded timestamp rather than client receive time, which could stall animation under clock skew, but the fallback behavior is a static chart rather than a crash or data corruption.

frontend/components/network-activity-tracker/tps-chart.tsx — specifically the progress formula in drawHistory if TPS timestamps are server-originated.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["useSlidingNow (rAF setState now)"] -->|now every frame| B[TpsChart render]
    C["useTps history"] --> B
    B --> D["drawHistory history now"]
    D --> E{history.length < 2?}
    E -- yes --> F[return history unchanged]
    E -- no --> G["duration = target.ts - from.ts"]
    G --> H{duration <= 0?}
    H -- yes --> F
    H -- no --> I["progress = clamp 0 to 1"]
    I --> J["head = lerp from to target at progress"]
    J --> K["chartData = history slice plus head"]
    B --> L["buildTicks windowStart now"]
    L --> M["step = first TICK_STEPS >= span/6"]
    M --> N["ticks anchored at now stepping back"]
    K --> O["AreaChart domain windowStart to now"]
    N --> O

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
frontend/components/network-activity-tracker/tps-chart.tsx:68
**Animation progress anchored to server timestamp, not client receive-time**

`progress` is computed as `(now - target.timestamp) / duration`, where `target.timestamp` is the timestamp embedded in the TPS data point. If those timestamps originate from the server clock, any client–server skew shifts the entire animation window: a client clock that lags the server will keep `progress` at 0 (clamped) until its clock catches up to `target.timestamp`, freezing the head at `from` and silently dropping the newest segment from the chart. The safe fix is to record the client-side receipt time and drive progress from that instead — e.g. store `receivedAt = Date.now()` alongside each incoming point and use `(now - receivedAt) / duration`.

_{Reviews (4): Last reviewed commit: "fix the x absis to have only 1 now" | Re-trigger Greptile}